[MOD-17706] finalize SVSIndex::relabelVector - #1045

Two changes to the bindings, both needed before any of this could be tested
from python:

`relabel_vector` had no binding at all, so no flow test could reach it. Bind it
on PyVecSimIndex, which serves every index type, and expose VecSimRelabelCode so
a caller can tell the rejections apart rather than compare bare ints.

`get_vector` was already bound, but its dispatch treated "not brute force" as
"is HNSW". SVSIndex derives from VecSimIndexAbstract, not HNSWIndex, so the
dynamic_cast returned nullptr and the virtual call dereferenced it -
`svs_index.get_vector(label)` was a segfault, which is why the SVS
getDataByLabel merged in #1033 was unreachable from python. `getDataByLabel` is
a pure virtual on VecSimIndexAbstract, so the algo switch was never needed: call
it virtually and brute force, HNSW and SVS are all served. A tiered index wraps
two VecSimIndexAbstract instances rather than being one, so it keeps its own
branch - that fixes the same latent null dereference for tiered, which was
pre-existing and unrelated to SVS.

Flow tests cover both APIs, single and multi, across every index type. Multi is
not a formality here: a label owns several vectors and each backend moves them
by a different route, and a move onto an occupied label must be rejected because
accepting it would silently merge two labels' vectors rather than lose one.

The tiered test relabels an early label and the last-inserted one. Workers
ingest in insertion order, so the early one is already in HNSW while the late
one is still buffered with pending ingest jobs - measured at ~690 of 1000 still
buffered at relabel time - so both tiers get covered. The buffered case is the
delicate one: a job left holding the old label would either ingest under it or
throw out of a worker thread.

The SVS flow tests probe the build with a no-op relabel and skip when it reports
unsupported, since python cannot see HAVE_SVS_REPLACE_EXTERNAL_ID. The probe
uses equal labels, which is answered before `impl_` is touched, so it works on
an empty index and cannot mask a broken implementation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The guard added a worse failure than the one it removed, as @dor-forer spotted.
`PyHNSWLibIndex::createBatchIterator` takes `indexGuard` in shared mode and
holds it until the iterator is destroyed, releasing it from the iterator's
deleter. `std::shared_mutex` is neither recursive nor upgradeable, so

    it = index.create_batch_iterator(query)
    index.relabel_vector(7, 70)

blocks on a lock the calling thread already holds: undefined behaviour, in
practice a hang. That is reachable from ordinary single-threaded use, whereas
the race the lock addressed needs two Python threads -- `knn_parallel` joins its
workers before returning, so it can only overlap a relabel issued from another
thread.

So relabel goes back to being unguarded, which is also what `add_vector` and
`delete_vector` beside it do: this binding leaves serialisation to its caller.
The reason is now stated at the method, since "no lock here" is the kind of
thing that reads like an oversight.

Guarding it properly means not holding `indexGuard` across a batch iterator's
whole lifetime, which is pre-existing and its own change. A narrower option, if
we want one here: count live iterators on the index and have relabel raise a
Python error rather than block when one is alive.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`addVector`, `knn`, `range` and the batch iterator's `getNextResults` all
release the GIL around their index call; `deleteVector` and `relabel_vector` did
not. For relabel that is not just an inconsistency: on a tiered index it takes
`mainIndexGuard` exclusively, and a live batch iterator holds that guard shared
until it is depleted or freed, so relabel blocks there. Blocking while holding
the GIL stops the Python thread that owns the iterator from ever running to
release it, turning a wait into a cross-thread deadlock.

Releasing cannot self-deadlock, unlike taking `indexGuard` here.

It does not help the single-threaded case, where the same thread owns both the
iterator and the relabel and no amount of GIL handling saves it. That is a
property of tiered relabel taking the main guard exclusively where
`deleteLabelFromHNSW` takes it shared, and is tracked separately.

`deleteVector` has the same missing release; left alone as pre-existing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`SVSIndex::relabelVector` moved a label, but wrapping that index in a tier did
not inherit the ability: neither `TieredSVSIndex` nor `VecSimTieredIndex`
overrode `relabelVector`, so a tiered SVS index fell through to the interface
default and answered `Unsupported`. That is correct for a caller which honours
the code, but it meant a tiered SVS index never took the relabel path however
capable its backend was -- and tiered is how it is used.

Both tiers are asked, because a multi-value label routinely has copies in each
and a target taken in either would collide once the buffer drains. The backend
moves first, since it is the tier that can refuse -- `Unsupported` when built
against an SVS without `replace_external_id` -- and refusing after the buffer
had moved would leave the label half applied.

`updateJobMutex` is taken first, in the order `updateSVSIndex` takes its own
locks. That is not defensive: an update job snapshots the buffer's labels *by
value* and afterwards reconciles only id swaps and deletions, so a rename
landing between the snapshot and the backend insert is invisible to it and the
vector reaches the backend under the old label, leaving it under both.

All three guards are held across the checks and the mutations. Checking under
shared locks and reacquiring exclusively would be cheaper for rejections, but
`std::shared_mutex` cannot upgrade, and async `addVector` and `deleteVector`
need neither `updateJobMutex` nor a held guard -- so either could land in the
gap and leave the move applied to one tier only.

Tests mirror what insertion has for this mode. `MovesTheLabelInBothWriteStates`
covers buffered-with-a-pending-job and moved-to-the-backend, the states
`addVector` and `insertJob` cover; `RejectsOnATier` covers each code, with the
taken target tried in both tiers; `DuringUpdateJob` is the `insertJobAsync`
analogue, relabelling 200 labels against live workers. The fixture's type set
spans single, multi and Quant_8, so this also answers whether a compressed
backend can move a label: it can, since `replace_external_id` renames an id and
never touches the stored vector.

`CannotLandInsideAnUpdateJobsWindow` is what pins the mutex, via the
`UpdateJob::before_add_to_svs` tracing hook that sits exactly in the window.
Worth stating why it exists: `DuringUpdateJob` still passes with the mutex
removed, so concurrency alone does not demonstrate the need. The hook test
fails, reporting a label count of 2 for one vector. It relabels from another
thread, since the job holds the mutex throughout and relabelling inline would
block on a lock the thread already holds.

Not added: relabel concurrent with a query. The tiers share
`VecSimTieredIndex::topKQueryImp`, so SVS inherits the cross-tier duplicate that
#1047 fixes, and such a test belongs with that fix rather than failing here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`test_svs_tiered.py` had eleven insertion tests and no relabel coverage, which
is how the tier answering `Unsupported` went unnoticed. Now that it moves a
label, exercise it through the binding as well, following the helper-plus-thin-
wrappers shape the insertion tests use, across unquantized, 8-bit, LeanVec 8x8
and FLOAT16.

Thresholds are small enough that ingestion is under way when the relabels run,
so the moved labels land in both states -- one early label already in the
backend, one late label still buffered -- and the assertions after
`wait_for_index` are what fails if an in-flight update job ingested a vector
under the label it snapshotted rather than the one it now has.

`get_vector` is only asserted for the unquantized configuration: a compressed
backend reports no stored values, so there the move is checked by searching for
the vector and expecting the new label, which holds either way.

Multi is not covered because a multi-label tiered SVS index is unsupported and
`IndexCtx` asserts against it.

Not run locally: `make pybind` fails before compiling, on CMake 4.4.1 against
pybind11's `cmake_minimum_required(<3.5)`. CI is the first execution of these.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`relabelVector` and `relabelVectorRejects` were plain `TEST(SVSTest, ...)`, not
`TYPED_TEST`. The suite name matched the typed fixture, which made them look
parameterized, but they built one index inline with no `quantBits` and ran
twice rather than six times -- so `replace_external_id` under quantization was
never exercised on a plain index, only through a tier.

Converting them needed the distance assertions rethought. They demanded exactly
0 for a vector's own query, which only holds unquantized. Capturing the distance
before the move and requiring it unchanged afterwards says what the test is
actually for -- a rename must not disturb the stored vector -- without assuming
what the distance is. It holds exactly in all three modes, so the move really is
bit-identical for the data.

`test_svs_multi.cpp` had no relabel coverage at all, though BF-multi and
HNSW-multi both do. A multi-value label is where a move that handles only the
label's first id still passes every single-value test, so each copy is checked
by its own distance, and an untouched neighbour label is kept alongside so a
move that is too broad shows up too.

Verified by mutation: returning OK without calling `replace_external_id` fails
`relabelVector` in all three modes and `relabelVectorMulti` with "copy 0 was
disturbed by the move", so the assertions are load-bearing rather than passing
because nothing moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`relabelVectorMarkedDeleted` existed only for plain HNSW. SVS reaches the same
contract by different means, so it is worth stating there too: SVS deletes
softly -- the entry is marked and only dropped by a later consolidation, so it
is still occupying an id -- but `has_id` excludes it, which is what makes the
move report the label absent rather than renaming a tombstone. The test also
adds the label back afterwards, to show the refusal left it free for reuse
rather than half-claimed.

The tier gets its own, because the delete can land while the vector is still
buffered or after it reached the backend and the label must be reported absent
either way, in whichever tier the delete missed. One thing that shaped it: no
tombstone is observable there -- `getNumMarkedDeleted()` reads 0 after the
delete, unlike on a plain index -- so it asserts the refusal and the absence
rather than the marking, and is named for what it actually covers.

Mutation notes, since the two tests differ in strength. Accepting a
marked-deleted label in `SVSIndex::relabelVector` fails the plain test in all
three modes. It does not fail the tiered one: `TieredSVSIndex::relabelVector`
checks `isLabelExists` itself before delegating, so both layers refuse
independently. The tiered test guards the contract across the two write states
rather than either single check.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

A test that never runs earns nothing. It was added skipped because the fix it
depends on is on another branch, which makes it dead weight here: it cannot
catch a regression, and the marker is one more thing to notice and remove later.
The deterministic coverage for this is the hook-based C++ tests on #1047, which
is also where a flow-level version belongs once that lands.

`import pytest` goes with it; nothing else in the file used it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CI caught this on Linux x86_64, where the build downloads a pre-built SVS
without `replace_external_id`: six failures, `relabelVectorMovesTheLabelInBoth
WriteStates` and `relabelVectorCannotLandInsideAnUpdateJobsWindow` across all
three type variants, the first reporting `Which is: 4` -- Unsupported -- where
it expected OK. `test_svs_tiered.cpp` had no occurrence of the macro at all,
unlike `test_svs.cpp` and `test_svs_multi.cpp`.

Gating the tests is only half of it, and the CI run shows why. The other three
tiered tests *passed* on that build, including `relabelVectorDuringUpdateJob`,
which asserts OK for two hundred moves. They passed because a rejection is
decided before the backend is consulted, and because a buffered label is
renamed in the flat buffer without asking the backend at all. So on Linux
x86_64 today, relabel on a tiered SVS index succeeds for a buffered label and
refuses an ingested one -- a capability that depends on which tier happens to
hold the label, which no caller can act on.

So `TieredSVSIndex::relabelVector` is gated too, mirroring
`SVSIndex::relabelVector`. Without the override the interface default reports
`Unsupported` for the whole tier, uniformly.

That also repairs the python probe. `svs_relabel_supported` asks
`relabel_vector(label, label)` and reads anything other than `Unsupported` as
capable, which is sound only while the method is absent; the tiered override
answered `SameLabel` before consulting the backend, so it would have looked
capable on a build that is not. The probe moves to `common.py` and the tiered
flow helper now uses it -- those tests were ungated in the same way, which the
review comment implies but does not spell out.

Verified both directions against real submodule checkouts. With
`replace_external_id` present: 15/15 tiered relabel runs pass. Without it
(submodule 7786d43, macro 0): compiles clean, and the only relabel test left in
the binary is `SVSTest.relabelVectorUnsupported` -- the `#else` branch that is
meant to be there -- which passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>